Most companies use computers to manage business and financial records. Large databases and various programs are used to keep track of all the information required for companies to do business. In the last decade the information that is stored as part of the databases has become accessible from the Internet and Intranet through Web-based applications. These applications dynamically generate a series of Web documents in a standard format supported by common browsers. Web-based applications are built using three-tiers: browser client, middle-tier application server and database server. The Web browser sends requests to the middle tier. The middle-tier services the request after accessing the database server with queries and updates.
An end user accesses a database through an application that is deployed on a middle tier. When the end user accesses the database through the application, the end user is authenticated by the application or middle tier service like SSO. Authentication credentials may include a username, password, SSL certificate, Kerberos ticket, or any other credentials that may be used to validate the identity of the end user.
Applications are typically developed with a database in mind. Even though many applications require user authentication before servicing user requests for data, in a typical scenario, once an application authenticates a user, any interactions between the application and the corresponding database does not involve the user's security credentials (or “context”), such as a user or group identifier, any roles assigned to the user, and zero or more attributes. In other words, the security credentials of the user are not leveraged by the database. Instead, any requests from the application to the database are sent along “privileged” connections. In other words, the application connects with the database as a highly privileged application user acting on behalf of the end user, regardless of whether the end user is highly privileged or lowly privileged. The “privileged” status indicates that the application can access all application tables, many database resources, etc.
When connecting as a highly privileged application user, the application establishes a session for the highly privileged application user. In one technique, the application may receive a query from a lowly privileged end user, query the database server in a session created for the highly privileged application user, receive a set of results from the database server that includes highly privileged data and lowly privileged data, and remove the highly privileged data from the results before sending the results to the end user. In this technique, the identity of the end user is unknown to the database and security is enforced only in the application that is deployed on the middle tier.
In a different security framework, instead of a mid-tier application enforcing security policies and removing highly privileged data from a set of query results from the database server, the database server is responsible for enforcing data security policies. Here, the mid-tier application sends an end-user's security context, such as a user identifier and any end-user roles to the database. Some mid-tier applications use language-level protection of users' security context, such as Java applications. Currently there is no direct integration between such mid-tier applications and database technology with respect to the security context.
One ad hoc approach to integrate a user's security context in Java with a database system is for a mid-tier application to call APIs to create and manage application sessions in the database and to update the user's security context if the user's security context changes. However, such an approach suffers from not being transparent, generic, secure, or efficient. Regarding transparency (or lack thereof), an application developer must programmatically call APIs (or send database statements, such as DMLs) to set up and use the security context. The ad hoc approach is not generic because different applications may implement the integration in different ways, even though the applications are solving the same problem.
Regarding the lack of security, the security context must be set up based on an authenticated user's identity. The security context should be stored internally in a secured manner and should not be tampered. However, the application usually does not have an infrastructure to support such secure storage. Additionally, the application treats the security context the same as normal application data. Such treatment can easily cause security issues and is error-prone.
Lastly, regarding lack of efficiency, the ad hoc approach results in unnecessary API calls and data propagation as well as inefficiency in using the security context.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.